JAN-30-2003 08:30AM FROM-FENWI CK4WEST SF 



415-395-0879 



T-077 P 014/030 F-086 




53. (Unamended) A computer prxSgram product stored on a computer readable medium 
for intermediation of real time meeting the computer program product comprising: 

program code for receiWan indication mat a requester party wants to request a real 

time meeting witivone or more target parties; 
program code forgiving information indicating the availability of the requester party 

and one or more target parties to participate in the real time meeting; 
program cod/for determining that the requester party and one or more target parties are 
mutually available to participate in the real time meeting, in response to the received 
wmation; and 

program cc^le for initiating the real time meeting, responsive to the determination that the 
requester/party and one or more target parties are mutually available to participate in the real 
time meeting. 



REMARKS 

In the above-referenced Office Action, the Examiner rejects claims 1-16, 28-49, 
and 53. The Examiner indicated that he had withdrawn claims 50-52 from consideration 
on the merits. 

Applicant has amended claim 1 and has amended claim 42 to correct a 
typographical error noted by the Examiner. 

Objections and Administrative Matters 

In the fourth paragraph, the Examiner indicated that Publication No.: 0 557 777 
Al contained in the information disclosure stated filed April 28, 2000 was not considered 
because it is not in the English language and no translation was submitted. Applicant 
respectfully submits that the English translation of the Publication No.: 0 557 777 Al was 
submitted at the USPTO in the Supplemental Information Disclosure Statement filed July 
14, 2000, and was so identified at that time. Applicant has received initialed form 1449 
attached to the Information Disclosure Statement of April 28, 2000. 
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In the fifth paragraph, the Examiner requested that the Applicant revise the 
abstract of the disclosure because lines 10- 1 1 of the abstract allegedly appear to reference 
the restricted elements of the pending claims. Applicant respectfully disagrees with the 
Examiner, since none of the restricted claims recite that some embodiments allow the 
user to choose from among queued requests. Applicant, however, has amended the 
abstract as requested in order to expedite prosecution. 37 CFR 1.72 states that "[t]he 
purpose of the abstract is to enable the United States Patent and Trademark Office and 
the public generally to determine quickly from a cursory inspection the nature and gist of 
the technical disclosure. The abstract will not be used for interpreting the scope of the 
claims." Applicant's amendment to the Abstract should not be used for the purposes of 
claim interpretation. 

In paragraph 6, the Examiner objected to the specification due to informalities. 
Applicant amended the specification accordingly. No new matter has been added by the 
amendments. 

In paragraphs 8 and 9, the Examiner objected to Drawings. Figure 2(d) is 
amended to delete reference numeral u 222". Applicant kindly requests that the Examiner 
approve corrections to the drawing as indicated by the attached drawing sheet for Figure 
2(d) marked-up in red ink in accordance with MPEP § 608.02(p). In addition, Applicant 
amended the specification to add the reference numerals 402, 404, 412, and 414 shown in 
Fig. 4. No new matter has been added by these amendments. 

Substantive Rejections 

The Examiner rejected claims 1-44, 49, and 53 under 35 U.S.C. § 102(e) as being 
anticipated by U.S. Patent No. 6,389,127 to Vardi et al. (hereinafter Vardi). This 
rejection encompasses all independent claims under consideration. 

Applicant's invention as recited in claim 1, for example, is a computer- 
implemented method for the intermediation of real time meetings. As described in 
Applicant's specification tbe claimed invention solves the problems involved when 
people play "phone tag" - a first person calls a second, who is not available, and when 
the second person calls the first, then the first person is not available, and so on. Thus, at 
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least one embodiment of Applicant's invention is directed to the problem of detecting the 
mutual simultaneous availability of a group of two or more people who are queued to talk 
to one another. It is important to understand that in the present invention, the parties do 
not learn each other's status. One drawback of a system such as Vardi is that the sought 
parties must agree to send their status to any system that asks for it, if they are to have a 
call connected with those parties. This is not always desirable. 

In an embodiment of the invention, normal operation is that the party who wants 
the call starts sending status.to a decider, which can be, for example, a system operated 
for or by the target. This status is sent by the requester when a call (not a status of the 
target) is first requested. It is important to note that requesting a call is different from 
requesting a target's status (as is done in Vardi). In Applicant's invention, the target does 
not, and is unable to request the status of the caller, and the caller does not and is not able 
to request the status of the target. Indeed, in at least one embodiment, the caller never 
sees the status of the target until such time as it is decided both parties are in and the 
connection is made, which implicitly reveals that status. Applicant's invention does not 
contain a "presence server" style system, described in Vardi because there are no status 
requests. 

To understand Applicant's invention,. it is important to understand its queue. 
When party A requests to call party B, ail that happens at first is that the parties 
remember this request. A's remembering it triggers A's system to send B the status 
when it changes, and B remembering it causes a "decider" (for example, on B's system) 
to accept those requests and combine them with its knowledge of B's status to make a 
decision. In certain embodiments, the decider can also be separate from B's system, and 
thus also be receiving B's status as it changes.) 

Existing systems do not have a means to allow party A to call party B when A is 
not known to B - other than by having B give up all privacy and offer status to anybody 
who requests it. Vardi seems to disclose such a system, in addition to a system that 
validates the seeking party before the sought party sends a status. Thus, in Vardi, party A 
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can request to pm B on her buddy or contact list and thus see B's status, but only if B 
consents after the fact or if B consents to the whole world seeing his status. ' ^ 

In Vardi, Party A can not push herself onto B's buddy list without B's consent, to ~ 
thus show B her status. B must again manually consent, or be willing to allow the world 
to add themselves to his list. As described below, Applicant's queue solves this problem. 

Specifically, claim 1 recites: 

receiving an indication by a requester system that a requester wants to 
request a realtime meeting with a target; 

sending to the target a request to conduct a real time meeting; 
queuing the request by the requester system; and 
connecting the requester and the target when the requester and the 
target are mutually available. 

Applicant disagrees with the Examiner's contention that Vardi's status request 
from a seeker to a sought system corresponds to claim l's recitation of sending to the 
target a request to conduct a realtime meeting. As noted, in Vardi, once a status is 
received by the seeker, a request for a call still needs to be placed. The portions of Vardi 
cited by the Examiner discloses sending a request for a status, not for a meeting/call. 
Vardi discloses a separate request for a call-back after a status is requested. 

In addition, the portions of Vardi cited by the Examiner do not disclose the recited 
queue. The term "queue" does not appear in Vardi and Applicant disagrees that the 
portions cited by the Exarniner disclose the claimed queue of requests. 

In the invention of claim 1, the system generates a queue of requested calls (as 
opposed to status requests or call-back requests). The system then operates on these 
queued requested calls by sending a status, causing it to be sent, rather than causing it to 
be requested, as in Vardi. 

Independent claim 9 recites at least the queue. 
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The other remaining independent claims recite at least that the requester sendTl 
status as a result of its request for a call. — 

The pending dependent claims depend variously from the independent claims 
discussed above and are patentable for at least the reasons discussed above. 

Respectfully submitted, 
BRADLEY S. TEMPLETON 



t^h- \*1 .2002 By: ^^V^O 




Laura Majerus, Reg. No. 33,41 
Attorney for Applicants 
Fenwick & West LLP 
Two Palo Alto Square 
Palo Alto, CA 94306 
Tel.: (415) 875-2332 
Fax: (415)281-1350 
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VERSION WITH MARKINGS Tf> Sw OW CHANfrF.K MAHB 
IN THE SPECIFICATION 

Paragraph beginning on page 4, line 29: 

System 100 also includes an operating system (not shown). A person of ordinary 
skill in the art will understand that the memory 104 and computer readable media 124 
may contain additional information, such as other application programs, operating 
systems, other data, etc., which are not shown in the figure for the sake of clarity. It will 
be understood that data processing system 100 (or any other data processing system 
described herein) can include numerous elements not shown in Fig. l£a), such as 
additional data, software and/or information in memory, disk drives, keyboards, display 
devices, network connections, additional memory, additional CPUs or processors, 
input/output lines, etc. 

Paragraph on page 16, line 29: 
Call-Waitinp 

Not only can trusted people get through when the user is holding calls, theyxan 
even get through when he is on the phone (see for example Figs. 9(aV9fcY) . This 
embodiment tells the user who the caller is, and allows in most cases a quick text 
message or reply, similar to instant messaging, implementation of which is known to 
persons skilled in the art In at least one embodiment, no beep sounds and thus, a person 
on the other end of the phone during a currently occurring telephone call does not know 
that another call is available to the user. 

Paragraph on page 7, line 19: 

Fig. 2(d) shows an embodiment in which a requester's system [236] 226 connects 
to a target's system 232 (or a target's proxy) via a network [234] 224, but in which the 
requester system connects to the target only via a telephone. For example, the requester 
may not have a software client installed on his computer. The requester can still indicate 
availability by calling the target system or a central server acting for the target (or the 



is 



Received from < 415 395 0879 > at 1130/03 1 1:35:39 AM [Eastern Standard Time] 



JAN-30-2003 08:32AM FROM-PENWICK&WEST SF 415-395-0879 T-077 P. 020/030 F- 



requester) and entering touch tones. Alternately, a target system can be a specially 
adapted telephone. 

Paragraph on page 7, line 25: 

Fig. 2(e) shows an embodiment in which a requester's system [242] 252 connects 
to a target's system [246] 256 via a network [244] 254 and in which a central server 
coordinates the management of calls for the user systems. In at least one embodiment, 
the queue of waiting messages and databases for priority and sorting are located on the 
central server. 

Paragraph on page 8, line 5: 

Fig. 3 is a flow chart showing a method for requesting and completing a realtime 
message (RTM) between a requester and a target. (An RTM is also referred to herein as 
a "call" because many embodiments of the invention, the purpose of the embodiment is 
to mediate telephone calls.) Examples of realtime messages include telephone calls, face 
to face meetings, and conference calls between two or more people. In element [304] 
302 of Fig. 3, a requester sends a message requesting a realtime meeting. This request is 
sent to one or more targets. Alternately, targets and requesters may be associated with 
each other in an arbitrary graph based on requests between parties. For example, user A 
may request a meeting with user B, and B may request to add user C. All three parties 
would become parties to the meeting. 

Paragraph on page 14, line 25: 

In element [808] 8J0, when the call ends, the system signals the end of the call to 
other servers and dequeues the call from the pending call list. Certain embodiments also 
log the call. In certain embodiments, the system also must explicitly state that its user is 
available. 

Paragraph on page 8, line 22: 

Hg. 4 is a flow chart showing queuing an RTM request. The queues generally 
reside on the user's systems. In a system with optional servers, if a user system receives 
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an RTM request from user A to user B, the system looks up servers that handle requests 
to call user B in element 402. [fo element 406, if] ff the system of user B does not accept 
the call in element 4 Q4, the system informs user A that the RTM request is denied in 
element 406 . Otherwise, in element 408, the RTM request is recorded on user A's server 
and the system asks B's servers to record an RTM request from user A in element 412 . 
The event is redisplayed in element 414. 

IN THE ABSTRACT 

A computer-implemented method and system for assisting in the intermediation 
of realtime meetings, including telephone calls and face to face meetings. A user informs 
his system that he wishes to, for example, make a telephone call. The system sends a 
request for a realtime meeting to the specified target. Both the target and the requester 
queue the request When both the requester and the target are mutually available, the 
realtime meeting can take place. Some embodiments cause this to happen automatically, 
some prompt the user to take action, such as dialing the telephone. [Some embodiments 
allow the user to choose from among queued requests.] 



DSJTHECT.ATMS 



1. (Once amended) A computer-implemented method for the intermediation of 
real time meetings, comprising: 

receiving an indication by a requester system that a requester wants to 
request a realtime meeting with a target; 

sending to the target a request to conduct a real time meeting; 
after sending the request, s ending by the requester a status of the 

requester: 

queuing the request by the requester system; and 
connecting the requester and the target when the requester and the 
target are mutually available. 
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42. (Amended) The system of claim 32, wherein the deciding agent is further 
adapted to receive an indication that the requester party and one or more target parties 
are available by monitoring the activity of the requester party and one or more target 
partieSi 
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Here are my notes from today. . 



inventions , the most succinct means is this. 

Key Differences: 

A queue of requests calls (as opposed to status requests or 
call-back requests) 4 or 

^ T.T «^ rQl ^ the Sending ° f status ' cau£ ™ it to be 
sent, rather than causing it to be requested 

The queue is task-oriented rather than buddy-Ust oriented 
as described in Vardi. When you have completed a S 
normally it is done and removed form the queue. 

sending^ prin * rily »° rks «• initial _ ca ll_ requester 

status to the target- . decider as it changes. The 

iSwV Ca ii- requescer is « ever * ..status requester 
asking for the status of the target's line as in Vardi. 

Vardi glosses over entirely the target receiving status from 

SV^r*^ ° f T Cal1 - ^ ™* be 

alt sS* "** SyStea desctib ^ for the requester to 

get status of the target, if , 0 . it's not the same as our 

uW« ""I" 41 automatically sends Status and 

i! ^ 1*1 V ? ° f loea11 * the call and having 

xt xn the local queue. * 

Our system is not contingent on a - call -back - , ie. the phone of 

it cSSJLS 1 ^ ^ Ph ° ne ° £ thS initi *tor. ms?ead 
call rh» «^ e „T a PP ro P Eiat « endpoints and has one 
^^.^ « ther -. The norm, for cost reasons, is for the 
tfle call egUlpment to dial the target's, and pay for 

111 V r2 i ;^. Call ; ba v k Can n0t be r «W»eed until one has queried 
the status of the user who will call you back. This is 
not true in our system and may be the best way of gettina 
our existing claims approved. 9 ^ 

in effect, their system is effectively ICQ with a call-back 
feature added. 

Extensions to our invention (queues, deleting, detection of 
mutual availability on a non-conference call) are not 
obvious Even 5 years after ICQ filed the Vardi patent, 
they still have not implemented any of it in their system. 
Documentation on their current telephony interfaces can be 
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found at: 

www. icq. com/ telephony/call-request .html 

problem Playing phone tas is now almos t » century-old 

which has cried out for a solution, which we present: 
Online -presence" indicators date back to the 60s or 'earlier, 
and online presence over the internet was created in the 
1971 by Les Earnest (a friend of mine, and on the Angel 
Investor list for the company, as it turns out. and I only 

it. 3USt * ° Ut ^ ^ research that * e was the one to start 

If the inventor of network presence thinks what I'm doing 
is novel that's pretty good evidence it is.) 

Things to add to our independent claim; 

The queue, possibly including deleting 

The requester of the call sending status, no queries 

Question: 

Would it be odd to offer the examiner a demo? i e a place 

SS r !J^! X ? min0 f . COU ^ d download some software and instructions 
and see the invention an action? Or would they not do this for 
security reasons? We don't have a web-only version but it's 
on our list. What about a demo recorded by one of those demo 
recording programs into a flash program or similar. 

So A SanS°Se ent °* inVenti ° n ' normal nation is that the party 

call starts sending status to a decider, which normally is a 

!^!V Pe T ed fOJ \? r * the tarset - This statu * " by the 

£ * (n0t StaCUS) ±S first "^sted, and if it 

should change. The target does not, and is unable to request the 

revest Caller ' ^ ^ *°* 3 n ° C ^ is not ^ to 

the status of the target. Indeed, in the basic embodiment, the caller 

never sees the status of the target until such time as it is decided 

both parties are in and the connection is made, which implicitly 

reveals * 

that status. 

There is no -presence server" style system, described in vardi as an 
apparatus for processing said status request" because there are not 
status requests. 

How does this work? The queue is essential. When party A requests to 
call party B. all that happens at first is that the parties remember 
this request. A Remembering it triggers A's system to send B the 
status when it changes, and B remembering it causes B's system to 
accept those requests and combine them with its knowledge of B's 
(Status to make a decision. 

(As we wrote it, this deciding agent can also be independent from B, 

and 
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thus also be receiving B's status as it changes, but this was to make 
the patent more broad.) 

This is novel because existing systems (even to this day and certainly 
at the time of filing of these two patents) do not have a means to 
allow party A to call party B when A is not known to B — other than 
by having B give up all privacy and offer status to anybody who 
requests 
it. 

That's because in existing art, party A can request to put B on her 
buddy 

or contact list and thus see B's status, but only if B consents after 
the 

fact or if B consents to the whole world seeing his status. 

Party A can not push herself onto B's buddy list without B's consent, 
to thus show B her status. B must again manually consent, or be 
willing 

to allow the world to add themselves to his list. 

To express An embodiment of the invention in terms of a system like ICQ 
or similar systems, it 
would be as though: 

a) Anybody in the world can add themselves to your buddy list, but 
only so you see their status, not so they see yours. 

bj Your system is set up so that if anybody does this, it combines 
their 

status with what it knows of your own status and then 

c) If both are mutually available automatically sends a message to 
the calling party with your current phone number or internet 
phone address or other channel 

d) The other party's system, getting that message, dials the call. 

(Plus a great deal more not noted in the patent — Maps of available 
devices, constant updates of those, exchange of various levels of 
information, 

picking the best device for call etc.) 

older ■■■^■■■■■■■■■■^■■■■■■■■■p«i 

Ok. I have the notes on the claims written up. The group of 
independent claims at the end of the patent are actually totally 
unrelated, 

they are claims for a system that would give you a telephone buddy 
list, 

so you could enter a set of phone numbers and see the status of those 
phones on your client or cell phone. So they are not an issue. There 
are only 2 independent claims in the patent. 

Claim 1 is, in effect, a description of: 

A phone line with a status that can be calculated and 
communicated 

to a computer B. 

A way for another computer A, using a network, to ask computer B 
about the status of the phone line, using its phone number. 

This is a very simple system, and really is nothing more than having 
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obviousness. ™ Sh ° Ul * haVe been denie <3 with prior art or 

is in v alid< but . is novel * when J£V!£L£?52S t claim 
StVi.fsr^lSSSS' cl T a S'oiLTS and is in f - 

your console showing if Tline'is S °" * ^5 fetence from light on 
using the phone number ^ " th&t y ° u make the request 

Curiously, one could imagine Drior fll -h A „ • 
original phone switchboard? w ?er J y£ hS I t* ?° in * back to 
marked with a number, with a lllL ™ ^ Series ° f jacks ' each 
and the operatorcouid till tl^JZ V° tSl1 y ° u if Lt '* in 

entire!^ tlfT ^ ° bfuScated ' but it -*e» to focus 
entirely in its claims on pretty different stuff t„ ^ ^ • , 

a line is busy i s just one possible input on that.) 

^don-t think if the examiner understands my invention they will think 
S oSerTkaTL 1 neSd t0 m0re "* to ~a"y understand 



************ 



rSS'BaTi^SleS'Jj'" ^ Splittin ^ int ° patents would add 

i* EL £ a patent that- rLo^ t^Tf 3 ' Pre " bly 10 «™> or -re 
pacent tftat s blown the budget until funding appears . 

(Though I am more optimistic about that) 

■Another option as I saw it was a claim rewrite that makes it -i.., th . f 
Mention 1011 8668 iS ' Th « ^ tS"* 

is^to detect the mutual simultaneous availability of a group of people 
are queued to talk to one another (have . real time meeting as X wrote 

uLfa^the llr ^ 2 A ? Simply * Very COWnon Stance of this, at 
product P " ««t«i. Though I have to admit that the 

starts by doing 2 and will expand to do more. 

conference n ° tin9 **** ^ ^ ^ by of doing the 

call feature already, though I have not seen anybody iplement it, nor 
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have I seen anybody write about it prior to my preliminary filing or 
of invention. 

However, another option is to abandon the other half to the whim of 
the examiner^ Can I re-file with just the first set of claimJ and 

be^iL™ ZlT g " for a while on the other clairas? or — *> th 

Or can I amend the patent with the first 17 claims, file a split off 
patent, but wait a long time for the office action on this, so that if 
there is no funding by then, 1 abandon it (USA only) then 
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